Systems and methods for digital refunds

ABSTRACT

Systems and methods for digital refunds are disclosed. According to one embodiment, in an information processing apparatus comprising at least one computer processor, a method for digital refunds may include: (1) receiving, from an issuing financial institution, electronic transaction data for a transaction involving a product purchased by a customer from a merchant, the product having a purchase price; (2) determining a return period in which the product may be eligible for a return to the merchant; and (3) during the return period: (a) retrieving a current price for the product from the merchant or a third-party merchant; (b) determining that the current price for the product may be less than the purchase price; and (c) initiating a refund to the customer from the merchant for a difference between the current price and the purchase price.

RELATED APPLICATIONS

This application claims priority to, and the benefit of, Indian PatentApplication No. 201911053540, filed Dec. 23, 2019, the disclosure ofwhich is hereby incorporated, by reference, in its entirety.

BACKGROUND OF THE INVENTION 1. Field of the Invention

Embodiments generally relate to systems and methods for digital refunds.

2. Description of the Related Art

After a customer makes a purchase for an item from a first merchant, acustomer may see the same item offered by a second merchant for a lowerprice. Currently, if the customer wants the lower price, the customercan either return the item to the first merchant for a refund andpurchase the item from the second merchant at the lower price, or thecustomer can request that the first merchant match the lower price.Either option requires considerable effort by the customer, and in thecase of the first option, results in waste and inefficiencies.

SUMMARY OF THE INVENTION

Systems and methods for digital refunds are disclosed. According to oneembodiment, in an information processing apparatus comprising at leastone computer processor, a method for digital refunds may include: (1)receiving, from an issuing financial institution, electronic transactiondata for a transaction involving a product purchased by a customer froma merchant, the product having a purchase price; (2) determining areturn period in which the product may be eligible for a return to themerchant; and (3) during the return period: (a) retrieving a currentprice for the product from the merchant or a third-party merchant; (b)determining that the current price for the product may be less than thepurchase price; and (c) initiating a refund to the customer from themerchant for a difference between the current price and the purchaseprice.

In one embodiment, the step of determining a return period in which theproduct may be eligible for a return to the merchant may includeretrieving a merchant return policy for the product. The merchant returnpolicy may be retrieved from a third-party aggregator using anapplication programmable interface (API).

In one embodiment, the step of retrieving a current price for theproduct from the merchant or a third-party merchant may includeretrieving the current price for the product from the merchant or thethird-party merchant using an API, retrieving the current price for theproduct from a third-party aggregator using an API, retrieving thecurrent price for the product from a distributed ledger, wherein themerchant or the third-party merchant are participants in the distributedledger, and the distributed ledger may include current prices for theproduct from the merchant or the third-party merchant, etc.

In one embodiment, the refund may be initiated when the differencebetween the current price and the purchase price meets or exceed athreshold amount. The threshold amount may be based on a dollar amountbetween the current price and the purchase price or a percent differencebetween the current price and the purchase price.

In one embodiment, the method may further include: receiving, from acustomer electronic device, a receipt for the product; extracting aproduct identifier and the purchase price from the receipt; and matchingthe extracted product identifier and purchase price to the product andpurchase price in the electronic transaction data.

In one embodiment, the method may further include saving a completedrefund to a database.

According to another embodiment, in an information processing apparatuscomprising at least one computer processor, a method for digital refundsmay include: (1) receiving, from a customer electronic device, a receiptfor a transaction involving a product purchased by a customer from amerchant; (2) extracting a product identifier and a purchase price fromthe receipt; (3) determining a return period in which the product may beeligible for a return to the merchant; and (4) during the return period:(a) retrieving a current price for the product from the merchant or athird-party merchant; (b) determining that the current price for theproduct may be less than the purchase price; and (c) initiating a refundto the customer from the merchant for a difference between the currentprice and the purchase price.

In one embodiment, the step of determining a return period in which theproduct may be eligible for a return to the merchant may includeretrieving a merchant return policy for the product. The merchant returnpolicy may be retrieved from a third-party aggregator using anapplication programmable interface (API).

In one embodiment, the step of retrieving a current price for theproduct from the merchant or a third-party merchant may includeretrieving the current price for the product from the merchant or thethird-party merchant using an API, retrieving the current price for theproduct from a third-party aggregator using an API, retrieving thecurrent price for the product from a distributed ledger, wherein themerchant or the third-party merchant are participants in the distributedledger, and the distributed ledger may include current prices for theproduct from the merchant or the third-party merchant, etc.

In one embodiment, the refund may be initiated when the differencebetween the current price and the purchase price meets or exceed athreshold amount. The threshold amount may be based on a dollar amountbetween the current price and the purchase price or a percent differencebetween the current price and the purchase price.

In one embodiment, the method may further include saving a completedrefund to a database.

In one embodiment, the refund may be issued as a credit to a financialinstrument used to conduct the transaction, using credit points, rewardspoints, miles, discount offers, or any other suitable promotional meansthe issuer may deem feasible through various products the issuer has.The refund may be offered as a transaction adjustment on the monthlystatement, or may be accumulated over a specific period of time andposted to customer's account (e.g., quarterly, every six months,annually, etc.) depending on the product and the terms and conditions.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, the objectsand advantages thereof, reference is now made to the followingdescriptions taken in connection with the accompanying drawings inwhich:

FIG. 1 depicts a system for digital refunds according to one embodiment;

FIG. 2 depicts a method for digital refunds according to one embodiment.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Embodiments are directed to systems and methods for digital refunds.

In embodiments, a customer making a purchase from a merchant may uploada purchase receipt for an item to an application or web service. Thereceipt may be from a digital wallet, an online purchase, or anin-person purchase. The purchase price may be extracted from thetransaction data sent by the merchant along with the item details when,for example, the customer uses an issuer specific card. The customer mayalso request that the merchant send the receipt to, for example, anemail address that may be associated with the issuer.

The application or webservice may be associated with the financialinstitution that issued the payment instrument used to purchase theitem.

The application or web service backend may then verify the customerpurchase, and may electronically monitor the pricing at the merchant andother merchants that may sell the item. For example, the backend maycheck online prices, etc.

If the merchant or the other merchants offer the item for a lower price,the backend may identity the price difference and automatically refundthe difference to the customer.

In one embodiment, the backend may electronically monitor the price forthe item during the return period for the merchant.

In one embodiment, the merchant may be charged a credit refund for theamount of the difference. In one embodiment, the merchant may also becharged a service fee.

Referring to FIG. 1 , an exemplary system for digital claims and/ordigital rebates is provided according to embodiments. Note that thenames of the systems involved are exemplary only and are not limiting.

System 100 may include customer 110 that may conduct a transaction for aproduct (e.g., a good or a service) with merchant 120. The transactionmay be conducted in person or online. Customer 110 may pay for thetransaction using a financial instrument such as a credit card (notshown), an electronic wallet, machine-readable code (e.g., QR codes), orpayment application (not shown) executed by electronic device 115, etc.

Electronic device 115 may be any suitable electronic device such assmartphones, computers (e.g., desktop, laptop, notebook, tablet, etc.),wearable devices (e.g., smart watches, rings, bracelets, necklaces,glasses, etc.), Internet of Things (IoT) appliances, etc. Any suitableelectronic device 115 may be used as is necessary and/or desired.

Merchant 120 may be any suitable provider of a product (e.g., a good orservice). Merchant 120 may include brick-and-mortar retailers, on-lineretailers, etc.

Merchant 120 may communicate with backend 130. Backend 130 may be abackend for a financial institution, such as the financial institutionthat issued the financial instrument involved in the transaction.Certain portions of backend 130 may be provided by a partner of thefinancial institution, a third party, etc. For example, if backend 130is provided by a third party, it would not include transactionauthorization system 134, but may instead receive transactioninformation from the financial institution.

Backend 130 may include a plurality of systems or modules, includingcredit adjustment system 132, transaction authorization system 134,digital receipt system 136, notification system 138, receipt uploadsystem 140, receipt OCR system 142, and price monitoring system 144.These systems or modules may be individual systems, may be part of alarger system, etc.

Credit adjustment system 132 may process a rebate for an eligiblerebate.

Transaction authorization system 134 may authorize the transaction frommerchant 120 using a financial instrument. Transaction authorizationsystem 134 may provide transaction details (e.g., merchant, productidentifier, price, date) to digital receipt system 136.

Digital receipt system 136 may receive a receipt from merchant 120and/or customer 110 and may itemize the product(s) on the receipt.Digital receipt system 136 may match a product on a receipt to a productidentified in a transaction received from transaction authorizationsystem 134. Digital receipt system 136 may receive current priceinformation and merchant return policies from price monitoring system144 and may initiate a rebate when a product is eligible for a rebate.

Notification system 138 may notify merchant 120 and/or customer 110 thatmerchant 120's conditions for a rebate have been satisfied and that arebate to customer 110 is being processed.

Receipt upload system 140 may receive a receipt upload from customer110. For example, a customer may email or send a text message with animage of a receipt to receipt upload system 140, may upload an image toreceipt upload system 140 from an application executed on electronicdevice 115, etc. In one embodiment, receipt OCR system 142 may read areceipt image from digital receipt system 136 (if necessary) or receiptupload system 140, and may extract raw transactional data, such as theitem and the price paid. The raw data is used by digital receipt system136 to electronically monitor pricing for the item.

Backend 130 may further include database 146, which may store digitalreceipt information (e.g., transaction date, receipt identifier,merchant name, transaction date, transaction payment details, itemprice, etc.), transaction lifecycle information (e.g., a transactionidentifier, a merchant identifier, a customer identifier, an item actualprice, a claim status, a fulfilment status, a product identifier, areceipt identifier, etc.), inventory details (e.g., a productidentifier, SKU data, purchase date, return policy identifier, returndate, etc.), merchant information (e.g., a merchant identifier, amerchant name, a merchant location address, a merchant online store URL,etc.), customer information (e.g., a customer identifier, a customername, a claim date, a claim identifier, etc.), and pricing information(e.g., a product identifier, a product price, a merchant identifier,etc.), etc. Database 146 may store additional and/or different data asis necessary and/or desired.

Price monitoring system 144 may electronically monitor merchant 120,merchants 150, and aggregator(s) 155 for return policies, pricing forproducts, etc.

Database 146 may further store information about completed refunds toprevent duplicate refunds for the same transaction.

In one embodiment, database 146 may include a distributed ledger or anysuitable immutable database, and any of credit adjustment system 132,transaction authorization system 134, digital receipt system 136,notification system 138, receipt upload system 140, digital receipt OCRsystem 142, and price monitoring system 144 may write to the distributedledger.

Merchants 150 ₁, 150 ₂, . . . 150 _(n) may include competitors tomerchant 120. Backend 130 may retrieve pricing for the product inquestion from one or more of merchants 150 ₁, 150 ₂, . . . 150 _(n).

Aggregator 155 may be a third party that aggregate return policiesand/or prices from merchant 120, merchants 150 ₁, 150 ₂, . . . 150 _(n),etc. Backend 130 may retrieve return policy information for merchant 120and/or pricing for the product in question from inventory aggregator155.

In one embodiment, aggregator 155 may be part of a distributed ledgernetwork (not shown) where merchants (e.g., merchant 120, 150 ₁, 150 ₂, .. . 150 _(n), etc.) may participate in the distributed ledger networkand may submit product price information, return policy information,etc.

Referring to FIG. 2 , an exemplary method for digital claims and/ordigital rebates is provided according to embodiments.

In step 205, a customer may shop for a product and may pay with apayment instrument issued by a financial institution. The product mayhave a purchase price. The customer may use a physical card, a digitalwallet, a payment app, etc. to complete the transaction. The customermay receive a digital or a paper receipt for the transaction.

In step 210, the merchant may submit the transaction data to itsmerchant acquirer, then to the card network (e.g., VISA, MasterCard),and ultimately to the issuer. This is a business as usual process.

In step 215, the transaction may be authorized, which may be a businessas usual process. A copy of the transactional data may be sent to asystem, such as a credit refund system, for electronic tracking andmonitoring. The credit refund system may persist the transactionmetadata (e.g., the transaction ID, the transaction amount, thetransaction date, the last four digits of the financial instrument,merchant ID, etc.).

In step 220, the customer may optionally image a copy of the transactionreceipt and upload it to a system, such as a digital receipt system,via, for example, a mobile application associated with the financialinstrument. Alternatively, if the merchant has a relationship with thefinancial institution, the merchant may send a digital receipt directlyto the system.

In one embodiment, the customer may give permission to the financialinstitution to interact and/or communicate with the merchant on thecustomer's behalf. This may be part of accepting terms and conditionsfor using the service.

In step 225, the product(s) on the receipt (from the merchant, thecustomer, or both) may be itemized by, for example the digital receiptsystem, and may be stored. In one embodiment, it may the transactionalmetadata from step 215 with receipt metadata, and if the metadatamatches, then the product may be added to the list of products toelectronically monitor or track.

In one embodiment, the digital receipts system may store data from thereceipt for analytics. It may also a copy of all the metadata (e.g., thetransaction ID, the transaction amount, the transaction date, the lastfour digits of the financial instrument, merchant ID, etc.) to atracking system, such as a credit refund system, to initiate thetracking process.

In step 230, a check may be made to see if the product is eligible forreturn. For example, certain products (e.g., computer software,perishable goods, etc.) may not be eligible for return under themerchant's policies. Other products may have a limited return period(e.g., 90 days, 30 days, etc.). In one embodiment, the length of thereturn period may vary based on the merchant, product type, etc.

In embodiments, certain information may be written to a distributedledger, such a blockchain, and retrieved to make this determination. Forexample, item details such as the manufacturer model numbers,manufacturer SKU codes, item specifications, price, price validitydates, return policies, geographic locations, etc. may be written to thedistributed ledger. Merchants, manufacturers, retail vendors, wholesalevendors, etc. may voluntarily submit product information to thedistributed ledger, either directly or by using a third-party service.The third-party pricing service may, for example, make API service callsto retrieve the data from the merchants, manufacturers, etc. and mayupdate the distributed ledger as necessary. The third-party pricingservice may be provided as a free service or as a paid subscriptionbased service that issuers and other interested parties can subscribe toget the latest price of items.

In embodiments, for each product to be electronically tracked ormonitored, the tracking system may make a call to a third-partyaggregator, such as a product inventory system, to obtain the returnpolicy period and other merchant related information (e.g., returnprocess policies, return process address, etc.) based on the merchantID. In another embodiment, the tracking system may obtain the returnpolicy period and other merchant related information from the merchantdirectly.

The tracking system may identify the product type and the merchant'sreturn period for the product type and, based on the purchase date,current data, and other metadata as is necessary and/or desired, maydetermine if the product is eligible for return to the merchant.

If the product is not eligible for return, in step 250, the process maystop.

If the process is eligible for return, in step 235, the tracking systemmay determine if the current price for the product warrants a refund.For example, for each of the products to be electronically tracked ormonitored, the tracking system may contact the third party or themerchant with the product SKU number and/or other metadata to retrievecurrent price(s) for the product. If the tracking system identifies acurrent price that is lower than the purchase price from the third-partyaggregator, the merchant, or a third-party merchant, the tracking systemmay initiate the refund with the merchant.

In embodiments, if the customer finds a merchant that is offering thesame product for a current price that is lower than the purchase price,the customer may take a screen shot, upload a picture of theadvertisement, provide a link, etc. to show that the product price islower than the purchase price, and may upload the image along with, forexample, a form with all the details of the new price of the product,merchant name, merchant location etc. The uploaded proof may be sent tothe tracking system for further verification and analysis. If accepted,the tracking system initiates the refund process with the merchant.

In embodiments, the current price may be determined using, for example,on-demand API calls, web crawlers, batch jobs, accessing a distributedledger, webhooks from the merchants/manufacturers/third-parties, etc.

In one embodiment, the price difference between the purchase price andthe current price may be required to meet or be greater than a threshold(e.g., a dollar amount difference, a percentage difference, etc.) beforethe price adjustment process is initiated with the merchant.

In one embodiment, machine learning may be used to determine thethreshold. For example, prior refunds involving the customer may be usedto identify the threshold (e.g., the customer only approved a refundwhen the difference between the current price and the purchase priceexceeded a certain dollar amount, a certain percentage, etc.). Inanother embodiment, history with other customers may also be consideredin identifying the threshold.

In one embodiment, steps 230 and 235 may be repeated as is necessaryand/or desired. For example, embodiments may configure a scheduler totrack the current price of the product by calling a product inventorysystem and/or the merchant at a frequent interval until the product isno longer eligible for return.

In step 240, the tracking system may notify the merchant of thetransaction and with metadata regarding customer acceptance of terms ofconditions on the return policy. The tracking system may then initiatethe refund process by sending the details needed to adjust thedifference in price.

In one embodiment, the tracking system may request the customer toauthorize the refund before the refund process is initiated.

In step 245, the merchant may transfer the difference between thepurchase price and the current price to the financial institution via,for example, a credit adjustment system. In embodiments, the creditadjustment system may inform the credit refund system of the successfulmoney/credit adjustment. The refund amount may be automatically creditedto the financial instrument used for the original purchase, may becredited as reward points, may be issued as a stored value instrument(e.g., a stored value card, a virtual financial instrument, etc.), maybe sent as a paper check, etc. In other embodiments, the credit may beissued as a discount offer or any other suitable promotional means theissuer may deem feasible through various products the issuer has. Therefund may be offered as a transaction adjustment on the monthlystatement, or may be accumulated over a specific period of time andposted to customer's account (e.g., quarterly, every six months,annually, etc.) depending on the product and the terms and conditions.

In one embodiment, the credit adjustment system may keep track of themoney transfer from the merchant to the bank for audit and historicalreasons. For example, money transfers may be written to a distributedledger.

In one embodiment the issuer may issue the refund the difference ofamount to the customer after a certain period (e.g., a certain number ofdays) after the return period to make sure the customer did not returnthe product after refund adjustment.

In one embodiment, the completed refund may be written to a distributedledger so that the customer cannot seek the refund twice. In anotherembodiment, the credit refund system may also track completed refunds toprevent the customer from being refunded twice, or to prevent thecustomer from later returning the item for the original purchase price.

In embodiments, the credit refund system may calculate any fees (e.g.,20% of the difference between the purchase price and the current price)and may credit the remaining amount to the customer's account (e.g.,credit or debit account). In another embodiment, in addition to, orinstead of, the customer fee, the credit refund system may charge a feeto the merchant.

The credit refund system may notify the customer of the adjustedamount/refund fulfillment.

In step 245, the tracking system may remove the product from the list ofproducts or services to electronically monitor or track. This may beoptional, and may depend on the merchant's policies. For example, amerchant may allow only one refunds; in another embodiment, the merchantmay allow multiple refunds. After the number of refunds is met, theproduct may be removed.

Hereinafter, general aspects of implementation of the systems andmethods of embodiments will be described.

Embodiments of the system or portions of the system may be in the formof a “processing machine,” such as a general-purpose computer, forexample. As used herein, the term “processing machine” is to beunderstood to include at least one processor that uses at least onememory. The at least one memory stores a set of instructions. Theinstructions may be either permanently or temporarily stored in thememory or memories of the processing machine. The processor executes theinstructions that are stored in the memory or memories in order toprocess data. The set of instructions may include various instructionsthat perform a particular task or tasks, such as those tasks describedabove. Such a set of instructions for performing a particular task maybe characterized as a program, software program, or simply software.

In one embodiment, the processing machine may be a specializedprocessor.

As noted above, the processing machine executes the instructions thatare stored in the memory or memories to process data. This processing ofdata may be in response to commands by a user or users of the processingmachine, in response to previous processing, in response to a request byanother processing machine and/or any other input, for example.

As noted above, the processing machine used to implement embodiments maybe a general-purpose computer. However, the processing machine describedabove may also utilize any of a wide variety of other technologiesincluding a special purpose computer, a computer system including, forexample, a microcomputer, mini-computer or mainframe, a programmedmicroprocessor, a micro-controller, a peripheral integrated circuitelement, a CSIC (Customer Specific Integrated Circuit) or ASIC(Application Specific Integrated Circuit) or other integrated circuit, alogic circuit, a digital signal processor, a programmable logic devicesuch as a FPGA, PLD, PLA or PAL, or any other device or arrangement ofdevices that is capable of implementing the steps of the processesdisclosed herein.

The processing machine used to implement embodiments may utilize asuitable operating system. Thus, embodiments may include a processingmachine running the iOS operating system, the OS X operating system, theAndroid operating system, the Microsoft Windows™ operating systems, theUnix operating system, the Linux operating system, the Xenix operatingsystem, the IBM AIX™ operating system, the Hewlett-Packard UX™ operatingsystem, the Novell Netware™ operating system, the Sun MicrosystemsSolaris™ operating system, the OS/2™ operating system, the BeOS™operating system, the Macintosh operating system, the Apache operatingsystem, an OpenStep™ operating system or another operating system orplatform.

It is appreciated that in order to practice the method of theembodiments as described above, it is not necessary that the processorsand/or the memories of the processing machine be physically located inthe same geographical place. That is, each of the processors and thememories used by the processing machine may be located in geographicallydistinct locations and connected so as to communicate in any suitablemanner. Additionally, it is appreciated that each of the processorand/or the memory may be composed of different physical pieces ofequipment. Accordingly, it is not necessary that the processor be onesingle piece of equipment in one location and that the memory be anothersingle piece of equipment in another location. That is, it iscontemplated that the processor may be two pieces of equipment in twodifferent physical locations. The two distinct pieces of equipment maybe connected in any suitable manner. Additionally, the memory mayinclude two or more portions of memory in two or more physicallocations.

To explain further, processing, as described above, is performed byvarious components and various memories. However, it is appreciated thatthe processing performed by two distinct components as described above,in accordance with a further embodiment, may be performed by a singlecomponent. Further, the processing performed by one distinct componentas described above may be performed by two distinct components.

In a similar manner, the memory storage performed by two distinct memoryportions as described above, in accordance with a further embodiment,may be performed by a single memory portion. Further, the memory storageperformed by one distinct memory portion as described above may beperformed by two memory portions.

Further, various technologies may be used to provide communicationbetween the various processors and/or memories, as well as to allow theprocessors and/or the memories to communicate with any other entity;i.e., so as to obtain further instructions or to access and use remotememory stores, for example. Such technologies used to provide suchcommunication might include a network, the Internet, Intranet, Extranet,LAN, an Ethernet, wireless communication via cell tower or satellite, orany client server system that provides communication, for example. Suchcommunications technologies may use any suitable protocol such asTCP/IP, UDP, or OSI, for example.

As described above, a set of instructions may be used in the processingof embodiments. The set of instructions may be in the form of a programor software. The software may be in the form of system software orapplication software, for example. The software might also be in theform of a collection of separate programs, a program module within alarger program, or a portion of a program module, for example. Thesoftware used might also include modular programming in the form ofobject oriented programming. The software tells the processing machinewhat to do with the data being processed.

Further, it is appreciated that the instructions or set of instructionsused in the implementation and operation of embodiments may be in asuitable form such that the processing machine may read theinstructions. For example, the instructions that form a program may bein the form of a suitable programming language, which is converted tomachine language or object code to allow the processor or processors toread the instructions. That is, written lines of programming code orsource code, in a particular programming language, are converted tomachine language using a compiler, assembler or interpreter. The machinelanguage is binary coded machine instructions that are specific to aparticular type of processing machine, i.e., to a particular type ofcomputer, for example. The computer understands the machine language.

Any suitable programming language may be used in accordance with thevarious embodiments. Illustratively, the programming language used mayinclude assembly language, Ada, APL, Basic, C, C++, COBOL, dBase, Forth,Fortran, Java, Modula-2, Pascal, Prolog, REXX, Visual Basic, and/orJavaScript, for example. Further, it is not necessary that a single typeof instruction or single programming language be utilized in conjunctionwith the operation of the system and method. Rather, any number ofdifferent programming languages may be utilized as is necessary and/ordesired.

Also, the instructions and/or data used in the practice of embodimentsmay utilize any compression or encryption technique or algorithm, as maybe desired. An encryption module might be used to encrypt data. Further,files or other data may be decrypted using a suitable decryption module,for example.

As described above, the embodiments may illustratively be embodied inthe form of a processing machine, including a computer or computersystem, for example, that includes at least one memory. It is to beappreciated that the set of instructions, i.e., the software forexample, that enables the computer operating system to perform theoperations described above may be contained on any of a wide variety ofmedia or medium, as desired. Further, the data that is processed by theset of instructions might also be contained on any of a wide variety ofmedia or medium. That is, the particular medium, i.e., the memory in theprocessing machine, utilized to hold the set of instructions and/or thedata used in embodiments may take on any of a variety of physical formsor transmissions, for example. Illustratively, the medium may be in theform of paper, paper transparencies, a compact disk, a DVD, anintegrated circuit, a hard disk, a floppy disk, an optical disk, amagnetic tape, a RAM, a ROM, a PROM, an EPROM, a wire, a cable, a fiber,a communications channel, a satellite transmission, a memory card, a SIMcard, or other remote transmission, as well as any other medium orsource of data that may be read by the processors.

Further, the memory or memories used in the processing machine thatimplements embodiments may be in any of a wide variety of forms to allowthe memory to hold instructions, data, or other information, as isdesired. Thus, the memory might be in the form of a database to holddata. The database might use any desired arrangement of files such as aflat file arrangement or a relational database arrangement, for example.

In the systems and methods, a variety of “user interfaces” may beutilized to allow a user to interface with the processing machine ormachines that are used to implement embodiments. As used herein, a userinterface includes any hardware, software, or combination of hardwareand software used by the processing machine that allows a user tointeract with the processing machine. A user interface may be in theform of a dialogue screen for example. A user interface may also includeany of a mouse, touch screen, keyboard, keypad, voice reader, voicerecognizer, dialogue screen, menu box, list, checkbox, toggle switch, apushbutton or any other device that allows a user to receive informationregarding the operation of the processing machine as it processes a setof instructions and/or provides the processing machine with information.Accordingly, the user interface is any device that providescommunication between a user and a processing machine. The informationprovided by the user to the processing machine through the userinterface may be in the form of a command, a selection of data, or someother input, for example.

As discussed above, a user interface is utilized by the processingmachine that performs a set of instructions such that the processingmachine processes data for a user. The user interface is typically usedby the processing machine for interacting with a user either to conveyinformation or receive information from the user. However, it should beappreciated that in accordance with some embodiments of the system andmethod, it is not necessary that a human user actually interact with auser interface used by the processing machine. Rather, it is alsocontemplated that the user interface might interact, i.e., convey andreceive information, with another processing machine, rather than ahuman user. Accordingly, the other processing machine might becharacterized as a user. Further, it is contemplated that a userinterface utilized in the system and method may interact partially withanother processing machine or processing machines, while alsointeracting partially with a human user.

It will be readily understood by those persons skilled in the art thatembodiments are susceptible to broad utility and application. Manyembodiments and adaptations of the present invention other than thoseherein described, as well as many variations, modifications andequivalent arrangements, will be apparent from or reasonably suggestedby the foregoing description thereof, without departing from thesubstance or scope.

Accordingly, while embodiments present invention has been described herein detail in relation to its exemplary embodiments, it is to beunderstood that this disclosure is only illustrative and exemplary ofthe present invention and is made to provide an enabling disclosure ofthe invention. Accordingly, the foregoing disclosure is not intended tobe construed or to limit the present invention or otherwise to excludeany other such embodiments, adaptations, variations, modifications orequivalent arrangements.

1. A computer-implemented method, comprising: receiving, by a backendcomputer system and from an issuing financial institution, electronictransaction data for a transaction involving a product purchased by acustomer from a merchant, the product having a purchase price, whereinthe backend computer system comprises at least one processor and adatabase, and the backend computer system participates in a distributedledger network in which a merchant aggregator system for the merchantaggregator, a merchant system for the merchant, and a third partymerchant system for a third party merchant are also participants;determining, by the backend computer system, a return period in whichthe product is eligible for a return to the merchant by retrieving amerchant return policy for the merchant from the merchant aggregatorsystem using an application programmable interface (API), wherein themerchant system submits its return policy to the merchant aggregatorsystem; and during the return period: retrieving, by the backendcomputer system, a current price for the product from the distributedledger network, wherein the merchant system and the third party merchantsystem submit their current prices for the product to the distributedledger network; determining, by the backend computer system, that thecurrent price for the product is less than the purchase price;initiating, by the backend computer system, a refund to the customerfrom the merchant for a difference between the current price and thepurchase price; and when the refund is complete, saving, by the backendcomputer system, the completed refund to the database. 2-6. (canceled)7. The method of claim 1, wherein the refund is initiated when thedifference between the current price and the purchase price meets orexceed a threshold amount.
 8. The method of claim 7, wherein thethreshold amount is based on a dollar amount between the current priceand the purchase price or a percent difference between the current priceand the purchase price. 9-20. (canceled)
 21. A system, comprising: amerchant aggregator system for a merchant aggregator; a merchant systemfor a merchant; a third party merchant system; an issuing financialinstitution; and a backend computer system comprising at least oneprocessor and a database, wherein the backend computer system, themerchant aggregator system, the merchant system, and the third partymerchant system are participants in a distributed ledger network;wherein the backend computer system: receives, from the issuingfinancial institution, electronic transaction data for a transactioninvolving a product purchased by a customer from a merchant, the producthaving a purchase price; determines a return period in which the productis eligible for a return to the merchant by retrieving a merchant returnpolicy for the merchant from the merchant aggregator system using anapplication programmable interface (API), wherein the merchant systemsubmits its return policy to the merchant aggregator system; and duringthe return period: retrieves a current price for the product from thedistributed ledger network, wherein the merchant system and the thirdparty merchant system submit their current prices for the product to thedistributed ledger network; determines that the current price for theproduct is less than the purchase price; initiating a refund to thecustomer from the merchant for a difference between the current priceand the purchase price; and when the refund is complete, saves thecompleted refund to the database.
 22. The system of claim 21, whereinthe refund is initiated when the difference between the current priceand the purchase price meets or exceed a threshold amount.
 23. Thesystem of claim 22, wherein the threshold amount is based on a dollaramount between the current price and the purchase price or a percentdifference between the current price and the purchase price.
 24. Anon-transitory computer readable storage medium, including instructionsstored thereon, which when read and executed by one or more computerprocessors, cause the one or more computer processors to perform stepscomprising: receiving, from an issuing financial institution, electronictransaction data for a transaction involving a product purchased by acustomer from a merchant, the product having a purchase price, wherein amerchant aggregator system for the merchant aggregator, a merchantsystem for the merchant, and a third party merchant system for a thirdparty merchant are participants in a distributed ledger network;determining a return period in which the product is eligible for areturn to the merchant by retrieving a merchant return policy for themerchant from the merchant aggregator system using an applicationprogrammable interface (API), wherein the merchant system submits itsreturn policy to the merchant aggregator system; and during the returnperiod: retrieving a current price for the product from the distributedledger network, wherein the merchant system and the third party merchantsystem submit their current prices for the product to the distributedledger network; determining that the current price for the product isless than the purchase price; initiating a refund to the customer fromthe merchant for a difference between the current price and the purchaseprice; and when the refund is complete, saving the completed refund to adatabase.
 25. The non-transitory computer readable storage medium ofclaim 24, wherein the refund is initiated when the difference betweenthe current price and the purchase price meets or exceed a thresholdamount.
 26. The non-transitory computer readable storage medium of claim25, wherein the threshold amount is based on a dollar amount between thecurrent price and the purchase price or a percent difference between thecurrent price and the purchase price.